Application messaging system with flexible message header structure

ABSTRACT

The Flexible Message Header (FMH) is a typed modular message structure comprising one or more Typed Container Modules (TCM)—stateful message modules with a compact header (Typed Container Header, TCH), a user definable payload (Typed Container Body, TCB), and a set of payload-specific callback to handle the lifecycle of the module at the different state such as creation, preparation, manipulation, resizing, transferring, and deletion. A single message comprises a small header with various numbers of TCMs. The integrity of the entire message is not affected by dynamically modifying, adding or removing TCM from the message. Major message content change can be achieved by either adding a TCM or swapping the TCM with different TCM. Minor message content change can be achieved by either modifying or expanding the TCM directly within the message. New features can be supported by adding new TCM and new code to process the new TCM.

[0001] This application claims priority from provisional application“APPLICATION MESSAGING SYSTEM WITH FLEXIBLE MESSAGE HEADER STRUCTURE”,Application No. 60/290,197, filed May 11, 2001, and incorporated hereinby reference.

[0002] This application is related to U.S. Pat. No. 5,265,250, filedMar. 29, 1990, and issued Nov. 23, 1993, which is incorporated herein byreference.

COPYRIGHT NOTICE

[0003] A portion of the disclosure of this patent document containsmaterial which is subject to copyright protection. The copyright ownerhas no objection to the facsimile reproduction by anyone of the patentdocument or the patent disclosure, as it appears in the Patent andTrademark Office patent file or records, but otherwise reserves allcopyright rights whatsoever.

FIELD OF THE INVENTION

[0004] The invention relates generally to messaging systems for use withdistributed application servers, and particularly to a flexible messageheader structure for communicating messages.

BACKGROUND OF THE INVENTION

[0005] In a distributed application system, such as those provided bythe Tuxedo system developed by BEA Systems, Inc., San Jose, Calif., mostof the distributed applications use tightly coupled messages tocommunicate. Adding or modifying message-related application featuresalmost always requires changing the message format, which has an impacton the rest of the software code that is exposed to the message. Thechange in message compatibility is an important issue in a multi-releaseenvironment.

[0006] BEA Tuxedo is just one example of such a messaging system.Earlier versions of the product have a fixed message format to supportall of the existing features at the time. The message format is exposedto almost the entire Tuxedo code base. In the past small changes to themessage format were made by using a few reserved fields in the message.Major additions to the messaging format were simply not allowed. Oneresultant problem with this approach is that a single fixed size messageformat makes use of the system resources and the network bandwidth in aless than efficient way.

[0007] The future growth of application server products such as Tuxedorequires an improved messaging system that is flexible enough tofacilitate adding major new features with little or no impact to theexisting code base. The messaging system should be efficient enough toreduce the message footprint for any features depending on it, withoutrewriting the code, and to be flexible enough to allow multi-releasedeployment without patching the older releases. Particularly, a solutionto the problem as it affects Tuxedo requires a new message header inorder to carry a longer Tuxedo service name and to reduce overhead bothon the queues, and over the network. In addition, future projectsrelated to application servers including Tuxedo, require a more flexibleformat than the existing message header so that different types of datacan be carried as part of the header without implying any dependencybetween the different types of data in order to access, manage oridentify each data type. Finally, overall throughput is an importantdesign criteria that should be balanced against the functionality of themessaging system.

SUMMARY OF THE INVENTION

[0008] The Flexible Message Header (FMH) of the invention is a new typedmodular message structure designed to be compact for efficiency,versatile for plug-and-play complex data type, simple for easy access,and clean for interoperability.

[0009] The Typed Container Module (hereinafter referred to as the TCM)is a stateful message module with a compact header (Typed ContainerHeader, hereinafter referred to as the TCH), a user definable payload(Typed Container Body, hereinafter referred to as the TCB) and a set ofpayload-specific callback to handle the lifecycle of the message moduleat the different state such as creation, preparation, manipulation,resizing, transferring, and deletion. All of the implementation of theTCM is total hidden behind a set of abstract interfaces such thatchanging the implementation of the TCM has no impact on the code that isusing it.

[0010] In accordance with the invention, a single message has a smallgeneric header with various numbers of TCMs. The relationship betweenTCM and message is clearly defined such that the integrity of the entiremessage is not affected by dynamically modifying, adding or removing aTCM from the message. This facilitates the handling of the messagecontent with great flexibility and efficiency at one end, and provides avery simple and efficient way to add new features at the other end.Major message content change can be achieved simply by either adding aTCM, or swapping the TCM with a different TCM. Minor message contentchange can be achieved simply by either modifying or expanding the TCMdirectly within the message. New features can be added simply by addingnew TCM and new code to process the new TCM.

[0011] The TCM solution provides several advantages such as thefollowing:

[0012] New features can be added by adding new code and new TCM withoutchanging the existing code.

[0013] The invention facilitates message content change with flexibilityand efficiency. Old and new releases of an application server that usesmessaging can be mixed in a single deployment without patching the oldrelease.

[0014] Reduction in message footprint by allowing each message to tailorits format to its exact need, instead of having a large common messageformat for all-purpose use.

[0015] Increased performance for forwarding messages by allowing thesystem to examine each message piece by piece.

[0016] Messages can be dynamically accessed at the TCM level directly.This provides flexibility and efficiency to the code that needs toaccess the message. By accessing message at the TCM level the systemallows the TCM to be prepared for local access (e.g. decoding,decrypting, and expansion) at different levels and at different placesby design, thereby enhancing performance and transparency.

[0017] Commonly used or mandatory TCM can be prepared at a very lowlevel in the system so that the upper level does not need to deal withit. Special or rare TCM can be passed up to the upper level withoutpreparation, which can then decide which step to take on the TCM.

[0018] For processes that are forwarding the message, the ability toaccess messages at the TCM level provides transparency by allowing thesystem to examine required TCM only, and without being affected by amessage having new TCM that is irrelevant to the process.

[0019] In a multi-release environment a message using TCM can passthrough an older release which may not know all the TCMs in the message,and it can forward the message along to its final destination which hasthe proper code to process the message. This is very useful in a verylarge or stable deployment by allowing incremental upgrade within arelease or selectively upgrading only part of a release.

BRIEF DESCRIPTION OF THE FIGURES

[0020]FIG. 1 shows the transfer of a message using a Flexible MessageHeader structure in accordance with an embodiment of the invention.

[0021]FIG. 2 shows a detailed view of an embodiment of the FlexibleMessage Header structure of FIG. 1.

[0022]FIG. 3 shows a detailed view of the pointer linking of FIG. 1.

[0023]FIG. 4 is a flowchart of a messaging process in accordance with anembodiment of the invention.

DETAILED DESCRIPTION

[0024] The Flexible Message Header (FMH) is a typed modular structurethat supports a series of Typed Container Modules (TCM). Each TCM is astateful message module with a compact header (Typed Container Header,TCH), a user definable payload (Typed Container Body, TCB), and a set ofpayload-specific callback to handle the lifecycle of the module at thedifferent state such as creation, preparation, manipulation, resizing,transferring, and deletion.

[0025] In accordance with one embodiment of the invention, a singlemessage has a small generic header, with various numbers of TCMs. Therelationship between TCM and message is clearly defined such that theintegrity of the entire message is not affected by dynamicallymodifying, adding or removing TCM from the message at design. This canfacilitate and minimize the overhead of handling the message contentwith great flexibility and efficiency at one end and provide a verysimple and efficient way to add new features at the other end.

[0026] Major message content change can be achieved simply by eitheradding a TCM or by swapping the TCM with a different TCM. Minor messagecontent change can be achieved simply by either modifying or expandingthe TCM directly within the message. New features can be added simply byadding a new TCM and new code to process the new TCM. Messages can bedynamically accessed at the TCM level directly. This provides aflexibility and efficiency to the code that needs to access the message.By accessing message at the TCM level the system allows TCM to beprepared for local access (e.g. decoding, decrypting, and expansion) atdifferent levels, and at different places thereby enhancing performanceand transparency.

[0027] The actual (detailed bit by bit) content of the message headeritself is not necessary for understanding the invention, although toshow how servers such as Tuxedo can benefit from this design, a simpledemo relating to Tuxedo is given to show the advantage of the design.

[0028] It will be evident to one skilled in the art that, while Tuxedois referred to herein for purposes of illustration, the invention is notlimited to this one particular brand of application server but maybeused with any messaging system or application server that uses messagingand should be afforded the broadest scope.

[0029] Definitions and Acronyms

[0030] Flexible Message Header (FMH)—A modular message structureconsisting of a Flexible Message Header and multiple TCMs.

[0031] STORAGE Mode—One of the data representations of the FMH. Thismode is suitable for queuing or sending over the network.

[0032] EDIT Mode—One of the data representations of the FMH. This modeis suitable for accessing or editing.

[0033] Typed Container Module (TCM)—The modular unit of the FlexibleMessage Header.

[0034] Typed Container Header (TCH)—The header of the Typed ContainerModule.

[0035] Typed Container Body (TCB)—The Body of the Typed ContainerModule.

[0036] TCM Table—A global table having all the known TCM types and theirassociated typed buffer type and subtype. A portion of the table can becompiled in, and other portions can be added by the API if TCMregistration is allowed.

[0037] TCM Pointer Set—A pointer pair that is part of the FMH and alsois a prefix to the TCM when the FMH is in the EDIT mode.

[0038] To take the example of Tuxedo the existing Tuxedo Message Headeris a 360 byte fixed format data structure which is not adaptive to theneeds of the future Tuxedo releases. In addition, there are fields whichare out-dated or fields which need to be re-structured to obtain betterperformance or support new features. In order to accomplish the abovetasks and extend the usefulness of the Tuxedo Message, a new generationof the Tuxedo Message Header designed in accordance with the inventioncan address these issues.

[0039] FMH Modulation

[0040] The FMH is a modular-based message header design with typedbuffer function support and unique identification. By modularizing theFlexible Message Header into functionally related groups, it canfacilitate protocol interoperability, multi-platform support, functionalplug-in and direct data manipulation at the module level.

[0041] Each module has a type to associate it with its functionality anda specific typed buffer entry to manage the module content at variousphases of the message lifecycle. Each module type has a unique TCM tableentry which has an index into the typed buffer table to assist with datacreation, preparation, flattening and platform conversion.

[0042] Module swapping allows messages to flow between differentversions of the application server (for example) Tuxedo implementation.By converting data from one module type to another messages can betransferred between different releases of Tuxedo implementations. Also,by encapsulating data inside, a typed module allows data to be examinedonly at the module level. This means that new data in the new module canbe transparent to the old Tuxedo implementation. This feature can beused to allow messages to carry data to be received by multiplerecipients who have different levels of knowledge of the messagecontent.

[0043] New modules can be introduced without affecting the rest of themessage header. Similarly, existing module can be removed. Modules canalso be manipulated, such as by decoding or decrypting, independentlyfrom the rest of the message content.

[0044] Modulation can reduce the footprint of the message header bypartitioning the message header into functional modules and onlytransferring those modules which are needed by the recipient. Modulationwith a unique identification for each module can support messages withmultiple TCMs having the same type at the same time, or during theentire message lifecycle. Assigning a unique identification for eachmodule. This allows inter-module correlation.

[0045] Typed Container Module (TCM)

[0046] The basic unit of the Flexible Message Header comprises a headerpart called a Typed Container Header (TCH) and a body part called TypedContainer Body (TCB). When the FMH is in EDIT mode, each TCM, except theone containing the user data, is prefixed with a TCM Attachment Unitwhich comprises two pointers,—one to point to the next TCM and the otherto point to the previous TCM in the message, together with a variable torecord the allocated size of the TCM. The TCM containing the user data(the User TCM) does not have the TCM Attachment Unit and is insteaddirectly attached to the FMH. When the FMH converts back into theSTORAGE mode from the EDIT mode, the TCM Attachment Unit is removed fromthe TCMs. Listing 1 shows an example of a TCM structure in accordancewith an embodiment of the invention. Listing 1 typedef sruct _tmtcm_tTCM; struct _tmtcm_t { unsigned short tmtcm_type; unsigned shorttmtcm_id; TM32U tmtcm_len; TM32U tmtcm_flag; TM32I tmtcm_udata; /* thebeginning of the TCB */ } typedef struct _tmtcmtb1_t TMTCMTBL structtmtcmtb1_t {  int count;  int tcmhash[TCM_MODULE + 1]; }; typedef structtmtcm_ele_t TMTCMELE; static struct _tmtcm_ele_t { unsigned shorttmtcm_type; char tbtype [TMTYPELEN]; char tbstype [TMSTYPELEN]; TM32Iflag; /* 0, reserved for future use */ int next_ele; /* next TCM elementin the free or TCM hash table */ }

[0047] Typed Container Header (TCH)

[0048] The header part of the TCM comprises a type field, ID field,length field, and a flag field with Header Extension Bits (HEB), whereinthese variables are defined as follows:

[0049] Type field—An index into a global TCM table.

[0050] ID field—A unique identification number during the messagelifecycle.

[0051] Length field—The size of the TCH plus the size of the used dataspace in the TCB. The actual size of the allocated space for the TCM canbe larger than the length field.

[0052] Flag field—The flags currently used are:

[0053] TCM_IN_USED—The TCM is in use.

[0054] TCB_ENCODE—The TCB is in “encoded” state.

[0055] TCM_UNKNOWN—The TCM is in an unknown state.

[0056] TCM_TTL—A flag indicating the TCM's time-to-live.

[0057] Header Extension Bits—The lower four bits of the flag field. TheHeader Extension Bits (HEB) are used to extend the TCH by increments offour bytes. 32 bit unsigned variables (which in the code examplesreferred to as TM32U variables; 32 bit signed integers are referred toas TM321 variables) are used so that the TCH can be decoded/encodedwithout the knowledge of its content. If the HEB is not zero then thelower four bits of the last four bytes in the extended TCH has to be thesame as the HEB. This allows traversing from the TCB back to the TCH.

[0058] The TCM_TTL flag indicates the TCM's time-to-live. The TTL flagis particularly useful when a message from a first process orapplication to a second process or application passes through, or isrouted by, an intermediate process. The intermediate process likely doesnot care about the content of the message itself, but may care aboutwhether it should or should not store the message, or any portion of themessage, in its memory space. The invention allows individual TCM's tohave different TTL values. Intermediate processes can use this TTL flagas an indicator of whether or not that particular TCM has changed sinceit was last sent. If the TTL flag indicates the TCM has not changed (forexample setting the TTL flag to zero), then the memory allocated to thisparticular TCM can be freed for other uses.

[0059] Typed Container Body (TCB)

[0060] This is the data portion of the TCM, and can be any binary dataformat. A typed buffer switch via the TCM type is used to administratethe TCB during the message lifecycle. Accessing the TCB is done in twosteps—the first step is an API call to locate the TCM containing theTCB; the second step allows direct accessing or editing of the TCBcontent.

[0061] Flexible Message Header (FMH)

[0062] The Flexible Message Header in accordance with the inventioncomprises a message header and one or more TCMs. In one embodiment theFMH has two modes; STORAGE mode and EDIT mode.

[0063] In STORAGE mode, the FMH is suitable for queuing messages orshipping them on the network. In STORAGE mode, the message is stored inone continuous memory space and all of the TCMs are stored without theirTCM pointer set.

[0064] In EDIT mode, the FMH is suitable for accessing or editing. InEDIT mode, the message may be scattered over several memory spaces. TheFlexible Message Header and the User TCM can be contained in onecontinuous memory space, and the rest of TCMs with their TCM pointer setcontained in one or more other continuous memory spaces. Listing 2 showsan example of a Flexible Message Header structure. Listing 2 typedefstruct _tmFMH_t FMH struct _tmFMH_t { char *tcmp_f; /* point to thetcmp_f of the next TCM */ char *tcmp_p; /* always to be NULL */ TM32Ibsize; /* memory size of the allocated space */ METAHDR mhdr; /* theTuxedo meta header */ TM32I magic; /* magic number for the memory spaceallocation */ unsigned short tmfmh_flag; unsigned short tmfmh_maxid; /*the maximum id in the message */ }

[0065] The FMH comprises a TCM attachment unit, a meta header, a flagfield, and a maximum ID field, wherein these fields are defined asfollows: TCM Attachment Unit—The TCM Attachment Unit includes twopointers to both the next and the previous TCMs respectively. It is usedonly when the message is in the EDIT mode, and also includes a sizevariable to indicate the allocated memory space of the FMH. The TCMAttachment Unit is not sent as part of the sent message.

[0066] Meta header—A 32 byte field included as part of the MessageHeader, and particularly the Tuxedo Message Header when the applicationserver is Tuxedo.

[0067] Magic—a magic number included as part of the Tuxedo MessageHeader when the application server is Tuxedo.

[0068] Flag (unsigned short)—Indicates the status of the FMH. The flagscurrently used are:

[0069] FMH_IN_USED—The message is in use.

[0070] FMH_EDIT—The message is in EDIT mode.

[0071] FMH_STORAGE—The message is in STORAGE mode.

[0072] Maximum id (unsigned short)—the maximum id field denotes thelargest identifier ever assigned to any TCM within the message. Itincrements by one every time a new TCM is added to the message. In oneembodiment the maximum number for this field is 65535. It is used toassure a unique id is associated to each TCM within the message.

[0073]FIG. 1 illustrates the various phases in which an original messagecan be generated, modulated, and stored at a recipient's location. Asshown in FIG. 1, the message may pass through a number of phases in itstransmission from one application to another. At a first application, amessage 102 is initially created comprising a header information portion104, a body information portion 106, and a user data portion 108. Duringan editing/modulating phase a Flexible Message Header (FMH) 110 iscreated, together with a number of Typed Container Modules (TCM) 111,115, 119, 123, each of which has a Typed Container Header (TCH) portion112, 116, 120, 124 and one of either a Typed Container Body (TCB)portion 114,118, 122, or a user data portion 126. The TCM's contain thefull content of the original header information, body information anduser data, divided between a number of TCM's. An Attachment Unit113,117,121 is added to each TCM that contains TCB information (in thisexample 111, 115, 119). The Attachment Unit provides pointers to boththe FMH (indicated by the arrow 128), and to the previous and successiveTCM's in the chain (indicated by arrows 130,132). A TCM containing noTCB information and instead only user data (for example TCM 123) is notprefixed with an Attachment Unit and is instead directly linked to theFMH via an independent pointer (indicated by the arrow 134). When themessage is received at the final destination and stored, the second(receiving) application retrieves only those TCM's for which it isconfigured to received. Other TCM's may be ignored. So, for example, thesecond application may choose to receive the entire message asoriginally sent, including the full header 104, body 106, and user data108; or it may choose to receive only header portion A 111, Headerportion B, 115, Body portion A 114, Body portion B, 118; or it maychoose to receive only header portion A 111, Body portion A 114, anduser data 126. Owing to the flexibility of the Flexible Message Headersystem, the application receiving the message can be configured to onlylisten for, receive and use a portion of the transmitted message. Thisallows for less network traffic at the receiving end, and greaterflexibility in modifying the messaging format at a later point in time,for example, for a new release of the application server, without havingto re-write existing application code.

[0074]FIG. 2 illustrates a detailed view of a non-user data TCM moduleduring the edit/modulation phase. Each TCM module (not including theuser data modules) includes a TCH header portion 204, and a TCB bodyportion 206. The header portion 204 comprises a number of fields thatare used to describe or type that particular module, and to distinguishthat module from others in the same message. These fields may include,in one embodiment, a Type field 212 which can be an index into a globalTCM table to denote the type of TCM; an ID field 214 for uniquelyidentifying the TCM during the message lifecycle; a length field 216 todenote the size of the TCH plus the size of the used data space in theTCB; and a flag field 218, wherein the flags may be any of (forexample): TCM_IN_USED—the TCM is in use; TCB_ENCODE—the TCB is in“encoded” state; TCM_UNKNOWN—the TCM is in an unknown state.

[0075]FIG. 3 shows how TCM's are linked to one another and to the FMHduring the edit/modulation phase. A TCM Attachment Unit is prefixed toeach TCM, other than those TCM's carrying only user data. User dataTCM's are linked directly to the FMH as shown in FIG. 1, and are notshown here for reasons of clarity. TCM's which contain a TCH and a TCBare linked through their Attachment Units, which contain pointers to thepreceding TCM (or the FMH) and to the succeeding TCM. In the examplegiven in FIG. 3, a first TCM 304 is prefixed with a TCM Attachment Unit312, which in turn contains a Last Unit pointer 314 to the FMH(indicated by the arrow 318), and a Next Unit pointer 316 to thesucceeding (second) TCM 308 (indicated by the arrow 320). The second TCM308 is prefixed with a TCM Attachment Unit 324, which in turn contains aLast Unit pointer 326 to the FMH (indicated by the arrow 320), and aNext Unit pointer 328 to the next TCM (indicated by the arrow 322). Theprocess continues for all TCM's comprising this particular message.

[0076] The method used by an embodiment of the invention in messagingbetween applications is shown in FIG. 4. In step 402 a first applicationwishes to send a message to a second application. In step 404, a messageis generated by the first application, together with header information,body information, and user data. In step 406, the header information andbody information is segmented or modulated into header modules, and theuser data is placed in a user data module. The Flexible Message Headeris then created (step 408), and in step 410 an attachment unit added toeach container module so that the container modules can be linked to theFlexible Message Header and to each subsequent container module insuccession. The user data module is independently linked to the FlexibleMessage Header (step 412). Modulated as such the message can be sent asa series of typed container modules to the recipient applications (step414), where in step 416 a second application can receive them, andselecting among certain of the container modules, reconstruct and storethe message according to its particular configuration needs.

[0077] Function Interfaces (API's)

[0078] The following section details various FMH-related functions thatmay be used by a developer in accordance with the invention tomanipulate or access the TCM, TCB, and FMH. The particular functionslisted here illustrate one embodiment of the invention. A detaileddescription of other API functions that can be used with the invention,including those not specifically related to the FMH header structure(such as the _tminitbuf( ), and _tmreinitbuf( ) functions), are given inthe related U.S. Pat. No. 5,265,250, incorporated by reference, whichalso contains additional detail on the functions described herein asthey pertain to non-FMH systems. It will be evident to those skilled inthe art that equivalent or alternative function calls can be used toeffect similar functionality, and are within the spirit and scope of theinvention. Listing 3 #if defined(_STRICT_ANSI) typedef TCBP void * #elsetypedef TCBP char * #endif

[0079] Register TCM Table Entry (_tmfmsg_regtcm)

[0080] int _tmfmsg_regtcm(unsigned short tcmtype, char*type,char*subtype, TM32U flag)

[0081] This function creates a TCM Table entry with the tcmtype as theunique key and its associated typed buffer type and subtype. Whensearching the corresponding typed buffer table entry, an Internal TypedBuffer Table is used first, then a User Typed Buffer Table. The searchstops at the first match of both the type and the subtype. Uponsuccessful completion, a new TCM Table entry is generated.

[0082] Deregister TCM Table Entry (_tmfmsg_dregtcm)

[0083] int _tmfmsg_dregtcm(unsigned short tcmtype, TM32U flag)

[0084] This function removes an existing TCM Table entry matching thetcmtype. Upon successful completion, the matching entry is removed fromthe TCM Table.

[0085] Locate TCM (_tmfmsg_loctcm)

[0086] int _tmfmsg_loctcm(unsigned short tcmtype, TM32U flag)

[0087] This function returns the results of the search for the specifiedtcmtype entry in the TCM table. Upon successful completion, the functionindicates that the given tcmtype is existing in the TCM table.

[0088] Create TFMM Object (_tmfmsg_create)

[0089] FMH*_tmfmsg_create(char*type, char*subtype, TM32U len, unsignedshort*id, TM32U flag)

[0090] This function generates a FMH object, and is typically the firstfunction called during a message preparation phase. Upon successfulcompletion, a FMH object is dynamically allocated with a FMH and a userTCM having the TCB size equals to len, and a pointer to the FMH isreturned with the pointer*id set to the tmtcm_id of the user TCM. Thereturned FMH is in the EDIT mode.

[0091] In some embodiments the User TCM module is added directly to theFMH to minimize the likelihood of it needing to be relocated in memoryat a later point in time. Since the user data can vary considerably bothin size and in content, placing it in this location reduces the chancesof it having to be moved again. Additional (non user data) TCM's, whichare typically more standard and smaller in size than User TCM's can thenadded on to the FMH. Since the non-user data TCM's are smaller in size,the fact that they may need to be relocated in memory at a later pointin time is not as important.

[0092] Add TCM module (_tmfmsg_addtcm(EDIT))

[0093] TCBP _tmfmsg_addtcm(FMH*msg, unsigned short type, TM32U len,unsigned short*id, TM32U flag)

[0094] This function attaches a TCM module to the FMH. Upon successfulcompletion, either a type TCM with len bytes of TCB is added to the FMHpointed to by the msg and the address of the new TCB is returned, or anexisting “unused” TCM which has a TCB larger enough is re-used and theaddress of the existing TCB returned. The value of the tmtcm_id of theTCM is stored in a pointer*id. The _tminitbuf( ) functions is called toinitialize the TCB. The inter-TCM sequence is not preserved.

[0095] This function does not apply to the User TCM—as described above,in some embodiments the User TCM module is added directly to the FMH tominimize the likelihood of it being relocated in memory at a later pointin time.

[0096] Count TCM (_tmfmsg_counttcm (EDIT))

[0097] int _tmfmsg_counttcm(FMH*msg, unsigned short type, TM32U flag)

[0098] This function retrieves the number of TCMs having type. Uponsuccessful completion, the total number of TCMs having type is returned.This function does not apply to the User TCM.

[0099] Find TCM (_tmfmsg_findtcm (EDIT))

[0100] TCBP _tmfmsg_findtcm(FMH*msg, unsigned short type, unsignedshort*id, TM32U flag)

[0101] This function searches the TCM having the required type and theunique identification. Upon successful completion, the TCB address ofeither the TCM having type and also the identification or the first TCMhaving type if id is found to be NULL is returned. This function doesnot apply to the User TCM. The TCB is automatically decoded if neededand a postrecv function called if needed.

[0102] Find user TCM (_tmfmsg_findutcm (EDIT))

[0103] TCBP _tmfmsg_findutcm(FMH*msg,, char*type, char*subtype, TM32Uflag)

[0104] This function searches the User TCM. Upon successful completion,the TCB address of the User TCM is returned. This function only appliesto the User TCM. The TCB is automatically decoded if needed and postrecvcalled if needed.

[0105] Resize User TCM (tmfmsg_rszutcm(EDIT))

[0106] TCBP _tmfmsg_rszutcm(_TCADEF, FMH**msg, char*type, char*subtype,TM32U len, TM32U flag)

[0107] This function changes the size of the TCB portion of the UserTCM. Upon successful completion, the size of the TCB is changed to lenbytes and the address of the re-sized TCB returned. The flag can be usedfor: TCM_NO_RESIZE—just to mark the new size and not do the reallocationwhen the new size is smaller than the old one; and TCM_RESET—to resetthe old TCB when copying to a new TCM or reset part of the TCB whenreducing the TCB size.

[0108] Resize TCM (_tmfmsg_rsztcm(EDIT))

[0109] TCBP _tmfmsg_rsztcm(_TCADEF, FMH*msg, TCBP tcbp, TM32U len, TM32Uflag)

[0110] This function changes the size of the TCB portion of the TCM.Upon successful completion, the size of the TCB is changed to len bytesand the address of the re-sized TCB returned. The flag can be used for:TCM_NO_RESIZE—just to mark the new size and not do the reallocation whenthe new size is smaller than the old one; and TCM_RESET_to reset the oldTCB when copying to a new TCM or reset part of the TCB when reducing theTCB size. This function does not apply to the User TCM.

[0111] Delete TCM (_tmfmsg_deltcm(EDIT))

[0112] int _tmfmsg_deltcm(FMH*msg, TCBP tcbp, TM32U flag)

[0113] This function invalidates a TCM from the FMH. Upon successfulcompletion, the TCM is deleted or marked as free from the FMH object.The flag can be used for: TCM_NOT_USED—just to mark the TCM being “notused” but do not free it; and TCM_RESET—to initialize the TCB to zero.This function does not apply to the User TCM.

[0114] Decode TCM (_tmfmsg_dectcm(EDIT))

[0115] TCBP _tmfmsg_decutcm(FMH*msg, TCBP tcbp, TM32U flag)

[0116] This function decodes a TCM. Upon successful completion, theaddress of the decoded TCB is returned. This function does not apply tothe User TCM. The function _tmdecdec( ) is called if needed.

[0117] Decode User TCM (_tmfmsg_decutcm(EDIT))

[0118] TCBP _tmfmsg_dectcm(FMH**msg, char*type, char*subtype, TM32Uflag)

[0119] This function decodes the User TCM. Upon successful completion,the address of the decoded TCB is returned. This function only appliesto the User TCM. The function _tmdecdec( ) is called if needed.

[0120] Presend (Edit) (_tmfmsg_presend(EDIT))

[0121] FMH*_tmfmsg_presend(FMH*msg, char*type, char*subtype, TM32U flag)

[0122] This function converts the FMH from the EDIT mode into theSTORAGE mode. Upon successful completion, either the msg is returned orthe address of a new FMH object is returned. The flag can be used for:ENCODE_TCM—encode all the TCMs (TCHs and TCBs). When the TCM is eitherencoded or unknown then the function _tmpresend( ) is not called.

[0123] Postsend (Edit, Storage) (_tmfmsg_postsend(EDIT, STORAGE))

[0124] FMH*_tmfmsg_postsend(FMH*msg, char*type, char*subtype, TM32Uflag)

[0125] This function converts the FMH from the after presend state backto the before presend state. When the TCM is either encoded or unknown,the function _tmpostsend( ) is not called.

[0126] Postreceive (Storage) (_tmfmsg_postrecv(STORAGE))

[0127] FMH*_tmfmsg_postrecv(FMH*msg, TM32U flag)

[0128] This function converts the FMH from the STORAGE mode into theEDIT mode. When the TCM type is unknown it will mark as unknown and the_tmpostrecv( ) function is not called, or if the TCM is encoded then_tmpostrecv( ) is not called. The User TCM is marked as unknown only.The inter-TCM sequence is not preserved.

[0129] Free Memory (_tmfmsg_free(EDIT, STORAGE))

[0130] int _tmfmsg_free(FMH*msg, char*type, char*subtype, TM₃₂U flag)

[0131] This function frees up the memory space of the FMH. Uponsuccessful completion, the FMH object is either marked as not used orfreed. The flag can be used for: FMH_NOT_USED—just mark all the TCM as“not used” but do not free it; and FMH_RESET—initializes all the TCBs tozero.

[0132] Initialize Buffer (_tmuninitbuf( ))

[0133] The _tmuninitbuf( ) function is called for each TCM if it is notunknown, encoded or not in-used.

[0134] A detailed description of other API function calls that can beused with the invention, including those not specifically related to theFMH header structure, is given in the related U.S. Pat. No. 5,265,250,incorporated by reference.

[0135] Macros

[0136] Macro functions can be used by the developer to retrieve usefulinformation about the state of the FMH, TCM and TCB, and to assist inthe messaging process. The macros shown here are given for purposes ofillustration.

[0137] GETTCB (tcmp)—This macro will return the address of the TCB fromthe address of a TCM.

[0138] GETTCM (tcbp)—This macro returns the address of the TCM from theaddress of a TCB.

[0139] ISTCBENC (tcmp)—This macro returns 1 if the TCB is encoded.Otherwise, it returns 0.

[0140] TCBSIZE (tcmp)—This macro returns the size of the TCB.

[0141] TCMID (tcmp)—This macro returns the unique identification of theTCM.

[0142] TCMTYPE (tcmp)—This macro returns the type of the TCM.

[0143] USERTCM(FMHP)—This macro returns the address of the User TCM fromthe address of the a FMH object.

[0144] FIRSTTCM (FMHp)—This macro returns the address of the first TCMfrom the address of a FMH object.

[0145] NEXTTCM (tcmp)—This macro returns the address of the next TCMfrom the address of a given TCM.

[0146] ISTCMUSED(tcmp)—This macro returns 1 if the TCM is in-used.Otherwise, it returns 0.

[0147] Some error codes that may be generated for these functions arelisted below:

[0148] TUX->_TUX_tperrno(TPEOS).

[0149] GP->_GP_Uunixerr(USBRK)—There is no available memory.

[0150] TUX->_TUX tperrno(TPENOENT)—The type and subtype are not in thetyped buffer table (TCM Table).

[0151] TUX->_TUX_tperrno(TPEMATCH)—The tcmtype is currently used in theTCM table.

[0152] TUX->_TUX_tperrno(TPEINVAL)—The flag is not 0 or the tcmtype ispart of the internal TCM table entries, or type is the User TCM type, ormsg is NULL or has the wrong state, or flag is not 0, or TCB size is 0,or tcbp points to either an User TCM or a not in-used TCM or a TCM inwrong state, or msg is NULL or has the wrong state, or TCB size is 0.

[0153] TUX->_TUX_tperrno(TPESYSTEM)—The _tminitbuf( ) failed or_tmencdec( ) failed or _tmpostrecv( ) failed, or _tmpresend( ) failed or_tmencdec( ) failed or TCH encode failed, or TCH decode failed or_tmpostrecv( ) failed, or -_tmuninitbuf( ) failed.

[0154] Message Flexibility and Integrity

[0155] The invention allows for great flexibility and compatibility inmessage handling throughout the release cycle. Since the end process(the receiving application) can be designed or configured to look for,or to read, only a particular portion of the FMH, or a particular subsetof TCM's, the FMH can be modified between releases (or between differentsystem architectures) to add extra functionality, while retainingcompatibility with older releases (or other system architectures). Anolder version of the application will simply ignore the TCM's it is notconfigured to read, or will render the TCM as an “unknown” type. The FMHis similarly capable of providing a message format that is machineindependent as well as release-independent.

[0156] One of the potential problems with this approach is that an olderrelease of an application or process may unwittingly accept a messagethat contains header information in a TCM it has rendered as “unknown”,but which in fact contains harmful code, for example a computer virus.To counter this, embodiments of the invention are particularly wellsuited to ensuring the integrity of the messaging process. This isparticularly important for security-related and secure applications. Inaccordance with this embodiment, the messaging system includes a “failon unknown” mechanism. A receiving application or process can beconfigured so that, if it receives a TCM it does not recognize, itfails, or rejects the message. A notification of the message failure isthen sent to the sending process. This mechanism can be used to assurethat the message is delivered with the integrity required by the sender.For example, the sender may specify a message with a format thatincludes a PKI (Public Key) security TCM. If the recipient is an olderrelease that does not recognize the PKI TCM, then delivering thatmessage would violate the senders requirements—in this case notdelivering the message is the safer option.

[0157] Industrial Applicability:

[0158] The methods required for registration resolution of TCM type areindependent of the context of this application, and are dependent on thecontext of who will use the APIs and how to manage the “type” and“subtype” space among the users. The TCM type creation mechanism can,for example, use a simple pre-assigned type space for each user orperhaps a hashing process for some pre-defined type name formats thateach user has to follow in order to quarantine an unique type.

[0159] The FMH provided by the invention changes the performancelandscape in comparison with a fixed format message structure. Thebalance between the performance gain at the network bandwidth saving andthe CPU processing when dealing with a smaller message header and theCPU overhead when dealing with a non-fixed format message structureshould minimize any performance penalty imposed on the actualapplication that uses the messaging system.

[0160] The important issue of performance is to choose a design that canprovide a flexible and generic framework that can support future growthand that only adds cost at the incremental level with a minimum initialoverhead. The FMH is one approach of using the modular concept toachieve that.

[0161] The other application servers on the market had no prior solutionother than the addition of unused fields which are not a viablelong-term solution. The TCM solution offered by the invention hasseveral advantages as following:

[0162] New features can be added by adding new code and new TCM withoutchanging the existing code.

[0163] Message content change is facilitated with great flexibility andefficiency. Old and new releases can be mixed in a single deploymentwithout patching the old release.

[0164] The message footprint is reduced by allowing each message totailor the FMH to its exact need instead of having a large commonmessage for all-purposes. Performance for forwarding message isincreased by allowing a system component such as a server orintermediate recipient to examine a examining message piece by piece.

[0165] The foregoing description of preferred embodiments of the presentinvention has been provided for the purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise forms disclosed. Obviously, many modificationsand variations will be apparent to the practitioner skilled in the art.The embodiments were chosen and described in order to best explain theprinciples of the invention and its practical application, therebyenabling others skilled in the art to understand the invention forvarious embodiments and with various modifications that are suited tothe particular use contemplated. It is intended that the scope of theinvention be defined by the following claims and their equivalence.

What is claimed is:
 1. A system for passing messages from a firstapplication to a second application in a distributed application servercomprising: a message modulator at a first entity for modulating amessage, each modulated message having a flexible message header and aplurality of typed container modules; and, a message receiver at asecond entity for demodulating said typed container modules toregenerate said message.
 2. The system of claim 1 wherein said typedcontainer modules include a typed container header portion defining thetype and length of the typed container module header; and, a typedcontainer body portion containing a portion of said message headerinformation.
 3. The system of claim 1 wherein one of said typedcontainer modules includes a user data portion.
 4. The system of claim 1wherein said message receiver demodulates only a subset of said typedcontainer modules to create said message.
 5. The system of claim 1wherein said typed container modules are linked to each other bypointers.
 6. The system of claim 1 wherein said typed container modulesare linked to said flexible message header by pointers.
 7. The system ofclaim 1 wherein the message header part of the flexible message headercomprises an attachment unit for linking to said typed containermodules.
 8. The system of claim 1 wherein said message modulatoroperates in an edit mode for editing and modulating a message, and astorage mode for storing a message, wherein in said edit mode, eachtyped container module, except those containing user data, is prefixedwith an attachment unit which comprises pointers to point to the nexttyped container module and the the previous typed container modules, andwherein in the said storage mode the attachment unit is removed from thetyped container modules.
 9. The system of claim 8, wherein in saidstorage mode, the message is stored in one continuous memory space andall of the typed container modules stored without their pointer set. 10.A method of messaging between applications in a distributed applicationsystem, comprising the steps of modulating a message, each modulatedmessage having a flexible message header and a plurality of typedcontainer modules; and, demodulating said typed container modules tocreate a message.
 11. The method of claim 10 wherein said typedcontainer modules include a typed container header portion defining thetype and length of the typed container module header; and, a typedcontainer body portion containing a portion of said message headerinformation.
 12. The method of claim 10 wherein one of said typedcontainer modules includes a user data portion.
 13. The method of claim10 wherein said message receiver demodulates only a subset of said typedcontainer modules to create said message.
 14. The method of claim 10wherein said typed container modules are linked to each other bypointers.
 15. The method of claim 10 wherein said typed containermodules are linked to said flexible message header by pointers.
 16. Themethod of claim 10 wherein the message header part of the flexiblemessage header comprises an attachment unit for linking to said typedcontainer modules.
 17. The method of claim 10 wherein said messagemodulator operates in an edit mode for editing and modulating a message,and a storage mode for storing a message, wherein in said edit mode,each typed container module, except those containing user data, isprefixed with an attachment unit which comprises pointers to point tothe next typed container module and the the previous typed containermodules, and wherein in the said storage mode the attachment unit isremoved from the typed container modules.
 18. The method of claim 17,wherein in said storage mode, the message is stored in one continuousmemory space and all of the typed container modules stored without theirpointer set.
 19. A method for messaging between applications in adistributed application system, comprising the steps of: generating amessage at a first application, together with message header informationand body information; segmenting the header information and bodyinformation into container modules; creating a flexible message header;attaching to each container module an attachment unit containingpointers linking the container module to the flexible message header andto each successive container module; sending the message as a series oftyped container modules to a second application; and, selecting at saidsecond application certain of the container modules and reconstructingthe message.
 20. The method of claim 19 wherein the message includes auser data portion.
 21. The method of claim 20 further comprising thestep of: placing said user data portion into a user data module andlinking said user data module to said flexible message header.